Today there is increasing use of integrated circuit cards, colloquially referred to as “smart cards”, in place of, or in addition to, conventional magnetic stripe cards (“mag cards”). A smart card is a thin card embedded with a memory device (volatile and/or non-volatile) and associated programmable or non-programmable logic. Unlike the mag card that merely stores “static” information (e.g., a credit card account number), a smart card can add, delete and otherwise manipulate information stored on the card. Accordingly, smart cards are capable of storing and executing applications to carry out one or more functions within a smart card.
A smart card is often referred to as a “closed” system because, for security purposes, a smart card is purposefully designed to not expose its memory, intermediate system states or data and address bus information to external devices. To do so would render it susceptible to unauthorized access (hacking) and fraud. While its closed nature is useful for secure applications such as banking transactions, it makes it difficult to utilize prior art smart cards for development purposes. It is to be appreciated that application development often requires access to memory or bus values, or system state information during intermediate processing steps, access that has been specifically designed out of the smart card.
Another encumbrance to the smart card application designer is the limited resources of the smart card. That is, due to the physical and processing constraints placed on the smart card, prior art smart cards do not enjoy any dedicated debug facilities. Aside from the limited processing and memory attributes of a smart card, a smart card typically has but a single, bi-directional input/output (I/O) port. The communication bandwidth of this single I/O port is typically consumed to support execution of the smart card application itself, leaving little to no communication bandwidth to support debug features. Thus, application development using a smart card itself is virtually impossible. Consequently the development of applications for a smart card currently requires the use of an in-circuit emulator (ICE) and an associated, often proprietary software development application.
As a result of the limited processing and memory capability of the smart card, and the cost of development, each smart card is typically developed to support a few functions. The smart card functionality is typically embodied as a couple of stand-alone runtime environment applets, stored within a non-volatile memory of the smart card, and selectively invoked by a host system. To better illustrate this architecture, a block diagram of a typical prior art smart card system architecture is presented with reference to FIG. 1.
As shown, from a hardware perspective, smart card 100 is comprised of an input/output (I/O) interface 102, control logic 104, non-volatile memory 106 and volatile memory 108, coupled as shown. Control logic 104 supports an operating system with native functions 110 and a runtime environment (RTE) 112, which executes runtime environment applets 114A and 114B accessed from non-volatile memory 106. The operating system 110 and RTE 112 are typically invoked when the smart card is introduced to a host system, e.g., a card reader, which provides power to smart card 100.
Because of the limited memory and processing capability of the smart card, the runtime environment 112 is typically optimized for the functions it performs, i.e., to implement the functionality embedded within applets 114. Moreover, storage of the applets themselves are optimized, i.e., the bytecode and data for the applets are compiled and stored as a single executable entity within one or more segments of non-volatile memory, as shown.
It should be appreciated that while the prior art runtime environment and applets were optimized to preserve the processing and memory capabilities of the smart card, they do not provide a flexible environment for, say, smart card applet development. One of the drawbacks of the self-contained applets typical of the prior art is that in order to change the functionality of an applet, the data must be replaced as well. That is, the code and data of the applet are inextricably tied together.
In addition to limiting the flexibility of the applets, compiling the code and data into a common file may, in certain circumstances, waste memory resources. That is, if two applets require the same data, the prior art dictates that two applet files, each with the same data, be stored in the non-volatile memory of the smart card. By eliminating this needless duplication, memory resources may be freed to extend the functional capability of the smart card.
Thus, a method and apparatus for sharing data files among runtime environment applets is required, unencumbered by the limitations commonly associated with the prior art. One such solution is presented below.